搭建基于 Snowflake 的 CI/CD 最佳实践！

Snowflake 提供了可扩展的计算和存储资源，和基于 SQL 的界面 Snowsight，方便用户进行数据操作和分析。然而，如果用户想将自己的 CI/CD 流程与 Snowflake 集成时，会发现一些不便之处（尤其相比其 SnowSight 优秀的查询能力）。

审核和发布流程

在 Snowflake 里，一个典型的更改工作流程如下：

1. 数据工程师在 Jira 中创建 schema 变更工单。

2. Snowflake 管理员审核该工单，然后使用 Snowsight 将更改应用到测试实例。

3. 数据工程师确认更改，并回复工单请求管理员将更改应用到生产实例。

4. Snowflake 管理员使用 Snowsight 将更改应用到生产环境。

5. 数据工程师确认更改并关闭工单。

上述过程有多个来回，且容易出错。例如：如果管理员错误地先将更改应用到生产环境会怎样？

缺少自动化的 SQL 语法检查规则

现代的 CI 流水线需要配有自动审核规则。对于 Snowflake 来说，这尤为重要，因为删除一个列可能会破坏下游数据流水线。而 Snowflake 并不提供此类语法检查。

GitOps

Snowflake 最近宣布了 Git 集成：https://www.snowflake.com/blog/snowflake-expands-developer-programmability-snowpark-container-services/

其中包括 Git 集成（预览版），可以轻松地将应用程序代码与 git 和 git 工作流进行集成。用户可以在 Snowflake 内部直接查看、运行、编辑和协作存在于 Git 仓库中的内容。

如果是类似 Vercel 的体验就更好了，当变更脚本合并到分支时，将自动触发一个滚动发布流水线，并可选择批准流程。

Bytebase：生而解决挑战

为应对 CI/CD 的挑战，Snowflake 打造了 schemachange (https://github.com/Snowflake-Labs/schemachange)。

而另一个解决方案则是 Bytebase，详细对比可见 schemachange vs. Bytebase (https://www.bytebase.com/blog/snowflake-schema-change/)。

基于 Web 的审查和发布流程

Bytebase 提供了基于 web 端的审核和发布界面，这类似 Jira，只不过是专门针对进行数据库变更的。例如，分阶段发布可将变更从测试直接发布到生产实例。

记录了 schema 变更历史。

检测由意外变更引起的数据库结构漂移 (schema drift)。

SQL 审核 + API

Bytebase 提供了一系列可配置的 SQL 语法检查规则，以检测 Snowflake SQL 反模式。配置完成后，在审核过程中将自动进行 SQL 审核。此外，可以从你的 VCS CI 调用 Bytebase API。

直接在 GitHub PR 中进行检查：https://github.com/bytebase/ci-example/pull/4/files

总结一下

Bytebase 将 DevOps 和类似 GitHub / GitLab 的体验带入了 Snowflake 世界，可以跟着手把手教程一起试试：https://www.bytebase.com/docs/tutorials/database-change-management-with-snowflake/。